查看原文
其他

喜马拉雅容器化实践

架构师 2023-06-18
架构师(JiaGouX)我们都是架构师!
架构未来,你来不来?


因公众号更改推送规则,请点“在看”并加“星标”第一时间获取精彩技术分享


喜马的容器化历程伴随着公司的发展,并带有很深刻的喜马的烙印:

  • 以 Java 项目为主;
  • Java 项目主要分为 Web 项目和 RPC 项目(基于公司自研的、类似 Dubbo 的框架);
  • 发布平台、RPC 微服务框架、网关自研。

在这个过程中,我们坚持了一些原则:

  • 开发不用写 Dockerfile,即开发不需要懂容器相关知识;
  • 测试环境下,开发的电脑可以直接访问容器,即 IP 可以互通。在任何环境,容器集群的物理机上的容器可以和其它物理机 IP 互通;
  • K8S 分为 Test、UAT、Product 三个环境,项目配置分为跟环境有关的部分和无关的部分,发布系统及项目信息 DB 部署在测试环境,发布系统可以跨环境访问 Test、UAT、Product 的三个 K8S 集群;
  • 项目启动失败后,保留现场,不要一直重启。


如何让开发发布代码到容器环境


2016 年底,我在 Jenkins 机器上安装了 docker,制作一个基于 docker 的项目模板。开发克隆 docker  项目模板,更改源码地址、CPU、内存等配置,由 Jenkins 触发 shell 脚本:

  • Maven 编译项目得到 war/jar 包;
  • 根据 war/jar 拼装 Dockerfile;
  • docker build 制作 docker 镜像并 push 到镜像仓库;
  • 调用 marathon 发布指令。

当时大概用了 5 天时间搭建了组件,跑通了所有步骤,我们的容器化事业就是从这个最low 的版本开始发展起来的,后来逐步做了以下演进:

  1. 从 marathon 逐步迁移到 Kubernetes。在过渡时期,我们自己实现了一个 docker  发布系统,对外提供发布接口,屏蔽 marathon 和 Kubernetes 的差异;
  2. 实现了一个命令行工具 barge。开发在项目文件中附加一个 barge.yaml 文件,里面设定了项目名等基本配置:
  • 开发只需 barge deploy 便可以发布项目,barge exec -m $projectName 便可以进入容器内调试代码;
  • 使用 Google jib 框架基于代码直接制作 docker 镜像,免去了开发电脑上装 docker 的要求,此外也将代码编译、镜像制作过程分散到了每个开发的电脑上,绕过了 Jenkins 单机负载的瓶颈;
  • 镜像仓库 harbor 的单词 含义的是海港(对应容器的集装箱)。大船是没办法直接开到海港的,到港口后要靠接驳船弄进去,接驳船英文是 barge,所以给项目起名叫 barge, 形容给 harbor 送镜像。至今仍很得意这个命名。
  • 与公司的发布系统对接(类似阿里云),屏蔽物理机与容器环境的使用差异。


  • 一个容器要不要多进程


    容器世界盛行的理念是:one process per container。但容器在最开始落地时,为了降低推广成本,减少使用差异过大(相比物理机)给开发带来的不适应,需要在容器内运行ssh,实质上要求在容器内运行多进程,这需要一个多进程管理工具(entrypoint不能是业务进程),最终在 runit/systemd/supervisor 中选择了 runit。

    此外,Web 服务每次发布时 IP 会变化,需要让 Nginx 感知到 Web 服务 IP 的变化。我们在每个容器内启动了一个 nile 进程,负责将项目信息注册到 ZooKeeper 上。使用微博一位小伙伴开源的 upsync 插件,并改写了部分源码使其支持了 ZooKeeper(upsync 只支持 etcd 和 Consul),进而使得 Nginx 的 upstream 可以感知到项目实例ip的变化。后来在另一个场景中,Nginx 改用了其它插件,我们将实例信息写入到 Consul 上即可。

    随着 Kubernetes 的铺开,我们使用 gotty + kubectl exec 逐步推广了在浏览器上通过Web console 访问容器。专门的网关系统也投入使用,HTTP 访问由 nginx => Web服务变成了 nginx => 网关 => Web 服务,网关提供了 Web 接口同步 Web 实例数据。ssh 及 nile 进程逐步退出历史舞台。目前,我们的 entrypoint 仍是 runit, 并对其做了微调,当业务进程启动失败时,不会重启(如果 entrypoint 是业务进程时则会频繁重启),以保留现场方便开发排查问题。


    健康检查的三心二意


    Kubernetes 有一个 readiness probe,用来检测项目的健康状态,上下游组件可以根据项目的 健康状态采取 相关措施。在 readiness probe 的设置上,经过多次改变:

    1. 每一个 Web 项目会提供一个 /healthcheck 接口,/healthcheck 通过即表示项目启动成功;
    2. 后来发现,对于 RPC 服务,/healthcheck 有时不能表示项目启动成功,需要检测RPC 服务启动时监听的端口是否开启;
    3. readiness probe配置(HTTP 和 TCP 方式任选)加大了业务开发的配置负担,经常出现配置不准确或中途改变导致 readiness probe 探测失败,进而发出报警,业务开发不胜其烦,我们也非常困扰;
    4. 于是将 readiness probe 配置为 exec 方式,由 nile 根据项目情况自动执行 HTTP 和 TCP 探测,但仍然依赖项目配置信息(比如 RPC 服务端口)的准确性;
    5. 基于“RPC 服务场景下,/healthcheck 接口成功,但 RPC 服务启动失败 的场景非常的少”的判断,我们将 readiness probe 改回了 HTTP /healthcheck 方式。

    liveness 起初是 /healthcheck

    1. 有一次运维改动机房网络,导致 liveness probe 探测失败(kubelet 无法访问本机所在容器 IP)。kubelet 认为 liveness probe 不通过 => livenessProbe 涉及到 RestartPolicy,大量项目重启 => 因为项目之间存在依赖关系,依赖服务失败,项目本身启动失败 => 频繁重启;
    2. 后来我们不再配置 liveness probe ,仅配置 readiness probe:对于物理机损坏等场景,K8S 可以正常恢复;如果容器内存不足 导致实例挂掉,K8S 无法自动重启,这个可以通过内存报警来预防。


    与发布平台对接


    喜马拉雅在发布平台的实践中,为了保障线上服务的稳定,沉淀了一套自己的经验和规则。其中一条硬性规定就是:服务端发布任何项目,最开始只能先发布一个实例,观察效果,确认无误后,再发布剩余实例。在实际使用时,验证时间可能会非常长,有时持续一周。这时,Kubernetes deployment 自带的滚动发布机制便有些弱。

    因此,在容器发布系统的设计上,我们让一个项目对应两个 deployment。新代码的发布就是旧 deployment replicas 逐步缩小,新 deployment replicas 逐步扩大的过程。业界有两种方案:

    • 每次发布新实例,都创建一个 deployment,扩大新 deployment 数量,缩小旧deployment 数量。
    • 每次发布新实例,都创建一个 deployment 作为灰度 deployment。灰度验证成功,则更新旧的 deployment。我们最开始使用的是第一种方案,缺点就是发布工作分散在两个 deployment 上,所有实例的销毁与创建速度无法控制。此外因为deployment 名字不确定,导致 hpa 配置比较麻烦。

    阿里的 openkruise 实现了一个 crd 名为 cloneset,可以实现上述类似的功能,后续计划逐步替换掉两个 deployment方案 以精简发布系统代码。全新设计一个crd 也是一个很不错的方案。

    此外,容器发布系统对下屏蔽 Kubernetes ,对上提供项目发布、回滚、扩缩容等接口,在接口定义上也多次反复。kubernetes client-java 库也较为臃肿,为此对发布代码也进行了多次优化。

    针对开发日常的各种问题,比如项目 IP 是多少,项目为什么启动失败等,我们专门开发了一个后台,起了一个很唬人的名字:容器云平台。试图将我们日常碰到的客服问题通过技术问题来解决,通过一个平台来归拢,哪怕不能实现开发完全自助式的操作,也可以尽量减少容器开发的排查时间。比如我们开发了一个 wrench 检查组件,用来扫描 Java 项目的 classpath、日志等,分析项目是否有 jar 冲突、类冲突、Tomcat 日志报错、业务日志报错等,开发在 Web 页面 上触发 wrench 执行即可。


    与已有中间件对接


    喜马有自己自研的网关及 RPC 框架,最初很少考虑容器的使用场景(比如每次发布 IP 会变化)。此外,服务实例需要先调用网关和 RPC 框架提供的上线接口,才可以对外提供服务。服务销毁时,也必须先调用下线接口,待服务实例将已有流量处理完毕后再销毁。

    为此我们提供了一个 k8s-sync 组件,监听 pod 状态变化,在适当时机调用实例的上下线接口。后续计划自定义 crd 比如 WebService/RpcService,由自定义 controller 完成实例的上下线及其它工作。

    如何做到 Web/RPC 服务的无损上线下线?

    上线

    pod 配置 readiness probe 对项目的 healthcheck 进行健康检查。健康检查通过后,pod 进入ready 状态, k8s-sync 监听到 pod ready事件,调用 Web/RPC 上线接口。readiness 由 K8S 确保执行,可保证健康检查不成功不会上线。风险是如果 k8s-sync  挂了则健康检查通过的 pod 无法上线。解决办法:

    • k8s-sync 容器部署,或者 systemctl 管理,挂了之后可以立即重启;
    • k8s-sync 通过 Prometheus 抓取数据,配置了报警,挂了之后可以迅速通知到容器开发。

    下线

    K8S 先执行 pod preStop 逻辑,preStop 先调用 Web/RPC 下线接口,执行 xdcs 提供的零流量检查接口,检查通过,则 preStop 执行完毕,销毁。若项目未接入 xdcs,则等待 preStop 等待 10s 后,执行完毕。销毁 => preStop 由 K8S 负责确保执行, 正常发布/删除/节点移除/节点驱逐 都可以确保被执行,以确保服务无损。如果物理机节点直接挂了,则无法保证无损,因为一系列机制都来不及执行。

    k8s-sync 同时也将 pod 信息同步到 MySQL 中,方便开发根据项目名、IP 等在后台查询并访问项目容器。随着 k8s-sync 功能的丰富,我们对 k8s-sync 也进行了多次重构。


    体会



    从 2016 年到现在,一路走来,容器的各种上下游组件、公司的中间件并不是一开始就有或成熟的,落地过程真的可以用“逢山开路遇水搭桥” 来形容。

    1、我们花了很大的精力在容器与公司已有环境的融合上,比学习容器技术本身花的精力都多。为此我经常跟小伙伴讲,我们的工作是容器化,其实质上容器技术“喜马拉雅化”。

    • 技术上与各种中间件做整合。为此开发了 k8s-sync,改造了 upsync;
    • 不要求开发 docker,写 dockerfile。为此开发 barge,容器云平台等。

    2、实践的过程仿佛在走夜路,很多方案心里都吃不准。为此看了很多文章,加了很多微信,很感谢一些大牛无私地交流。对于一些方案,走了弯路,兜兜转转又回到了原点。但这个过程逼得我们去想本质,去反思哪些因素是真正重要的,哪些因素其实没那么重要,哪些问题必须严防死守,哪些问题事后处理即可。

    3、成长经常不是以你计划的方式得到的。

    比如最开始搞 Kubernetes 落地的时候,想着成为一个 Kubernetes 高手,但最后发现大量的时间在写发布系统、k8s-sync,但再回过头,发现增进了对 K8S 的理解。

    笔者 Java 开发出身,容器相关的组件都是 GO 语言实现的,在最开始给了笔者很大的学习负担。但两相交融,有幸对很多事情理解得更深刻,比如亲身接触 Java 的共享内存模型与 GO 的 CSP 模型,最终促进了对并发模型的理解。

    为了大家多用容器,我们做了很多本不归属于容器开发的工作。尤其是在容器化初期,很多开发项目启动一有问题便认为是 docker 的问题, 我们经常要帮小伙伴排查到问题原因,以证明不是 docker 的问题。这是一个很烦人的事情,但又逼着我们把事情做得更好,更有利于追求卓越。比如 wrench 的开发,真的用技术解决了一个看似不是技术的问题。

    4、一定要共同成长,多沟通,容器技术改变了基础设施、开发模式、习惯,尽量推动跟上级、同事同步,单靠一个人寸步难行。

    最后想想,感慨很多,还是那句:凡是过往,皆为序章。

    如喜欢本文,请点击右上角,把文章分享到朋友圈
    如有想了解学习的技术点,请留言给若飞安排分享

    ·END·

    相关阅读:


    作者:李乾坤

    来源:qiankunli.github.io/2021/08/02/kubernetes_xima_practice.html

    版权申明:内容来源网络,仅供分享学习,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!

    架构师

    我们都是架构师!



    关注架构师(JiaGouX),添加“星标”

    获取每天技术干货,一起成为牛逼架构师

    技术群请加若飞:1321113940 进架构师群

    投稿、合作、版权等邮箱:admin@137x.com

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存